Night Owl 6/Night Owl's Shareware - PDSI-006 - Night Owl Corp (1990).iso/010a/dskctl20.zip/DSKSET.DOC

Text File | 1991-09-08 | 21KB | 409 lines

                                 DISK PARAMETERS


Are you thinking about replacing your old fixed disk with a newer, faster one?
If so, you may have discovered that you also need to replace your disk control-
ler.  DSKSET and DSKDRV are a pair of programs that could eliminate the need for
a new disk controller.

You may need a new controller to support your new disk for any of three reasons.

1.  Your new disk uses Run Length Limited (RLL) encoding to increase capacity
and transfer rate.

2.  Your new disk uses a new low-level interface such as the Small Computer
Systems Interface (SCSI) or Enhanced Small Disk Interface (ESDI).

3.  Your current disk controller does not have a disk type that matches the
physical characteristics of your new disk such as the number of heads and
cylinders.

If you need a new controller for reasons 1 or 2, there is nothing you can do
except to go ahead and make the investment.  However, very often you can get a
disk that meets all of your needs without having to use a different recording
mode or interface.  This is where DSKSET and DSKDRV can be useful.


SHAREWARE

DSKSET and its related products DSKDRV, DXTSET, DXTDRV, DISK, and BOOT are
shareware.  If you decide to use them after a reasonable trial period (1 month),
you are obligated to pay for them.  The fee for continued use is $10.  For this,
you may use the products indefinitely and I will send you notice of any updates
for one year.  For $25, I will send you the source code immediately and will
send you any updates for one year.  These fees apply to any use of the products
on a single computer including government agency and commercial use.  Volume
discounts and site licenses are available to reduce the cost for large users.

Send the fees and any inquiries to:

                        Ronald Q. Smith
                        11 Black Oak Road
                        North Oaks, Mn. 55127-6204

You may also contact me via CompuServ mail at userid 71620,514.  I will be
happy to respond to any problems and suggestions for future capabilities.

USING DSKSET

CONTROLLING THE CONTROLLER

Your controller comes with a table of disk parameter values, indexed by the disk
type that you specify through the system SETUP process on your PC/AT compatible
or through jumpers on the controller for your PC/XT compatible.  Your controller
may have from 4 to 255 disk types predefined.  Yet there are so many different
disks on the market, there is a good chance that your new disk is not one of
those supported.  DSKSET and DSKDRV allow you to install a parameter table that
matches that of your new disk.

First you will want to determine whether your disk controller supports your new
disk.  You may use the DISK utility with the TABLE and TAX parameters for a
display of the parameter table. See the sidebar THE FORMAT OF THE DISK PARAMETER
TABLE for a discussion of the table format.

If there is an entry in your disk controller's parameter table that exactly
matches your new drive, you need only run SETUP again to change the disk type to
select that entry.  If no entry matches exactly, run SETUP and select a type
that has the correct number of heads and sectors.  Then use DSKSET and DSKDRV to
get the rest of the values correct.  If you have an XT compatible, there should
be four to eight jumper (strapping) pin pairs on the controller card.  Half
determine the disk type for the first disk and half are for the second disk.
You will have to see your controller documentation or experiment a bit to figure
out the correct settings.

PC/AT AND COMPATIBLES

CREATING YOUR OWN TABLE

DSKSET.COM allows you to create a new disk parameter table entry from the DOS
command line.  DSKDRV.BIN allows you to create a new disk parameter table entry
within the CONFIG.SYS file.  Usually you will use DSKSET while you are format-
ting your new drive and loading the initial software on it.  You can try out the
parameter table to make sure you have done it correctly.  If it doesn't seem to
work, you can try a different set of values without having to reboot your
system.  Once everything is working correctly, put a DEVICE=DSKDRV.BIN statement
in your CONFIG.SYS file with the same parameters and you can boot from your new
disk.

DSKSET and DSKDRV expect the same set of input values.

DSKSET d p1,p2,p3,...
DEVICE=DSKDRV.BIN d p1,p2,p3,...

d is the disk drive number and must be 0 or 1.  Your drive will be drive 0 if it
is your only disk.  It will be drive 1 if you already have a disk and are adding
a second one.

p1,... specify the values for the 16-byte disk parameter table.  Each entry may
be a decimal or hexadecimal byte or word.  Decimal values consist of only the
digits 0-9.  Hexadecimal values contain one or more of the letters A-F, H, and X
(e.g., 9D, 0x42, 98H).  Byte values are 0-255(0-0xFF).  Word values are 256-
65535 (0x100-0xFFFF) or contain the letter W (e.g., 301, 2F8, W0, WF6).  If you
do not provide 16 bytes of information, trailing zero bytes will be added.

You may run DSKSET twice or include two DEVICE=DSKDRV.BIN statements in
CONFIG.SYS to specify parameter values for both drives 0 and 1.

HOW IT ALL WORKS

Most of the work in DSKSET and DSKDRV is done by a common subroutine DSKPARM.
Let's look at the unique parts first.  DSKSET actually starts at the label
DO_PARM.  It first displays our sign-on and copyright message and then calls
DSKPARM to process the command line input parameters.

DSKPARM is called with DS:SI pointing to the start of the input (in this case,
offset 81H where all command line parameters go) and ES:DI pointing to the
location to store the 16-byte parameter table.  We set ES:DI to point to offset
5CH in our segment as this is the first location that we are allowed to change.
Putting it here reduces the amount of resident space we are required to tie up.

DSKPARM returns with the value of the first parameter, the drive number, in AX
and the zero flag (ZF) set if everything was OK.  We will display an error
message if DSKPARM finds an error or if the drive number is greater than 1.

If everything was OK, we use the DOS set-interrupt-vector function call to point
the BIOS to our new parameter table.  We set interrupt number 41H if it is drive
0 and interrupt number 46H if it is drive 1.

Just pointing the BIOS to our new parameter table is not enough.  The BIOS
doesn't look at all of the parameter values on every disk I/O operation and we
must be sure that they all take effect.  So we now tell the BIOS disk handler to
reinitialize everything again.  We start off with a slight overkill by telling
the BIOS to reset the disk drive just in case it is in any funny state.  Then we
tell it to take the new parameters and reinitialize the controller.  Then we do
a reset again to be sure that everything starts from ground zero.

Now all we have to do is display our completion message and exit with the DOS
terminate-and-stay-resident function call.  We calculate the length of the
resident part by taking the offset of the parameter table that we created,
adding its length (16 bytes), and rounding up to the next paragraph boundary.

DSKDRV is DSKSET written as a DOS device driver.  At the start of every DOS
device driver there is a header block.  The first entry in the header is a
double word which DOS will use to link the device drivers together.  We ini-
tialize it to -1 per the rules for loading device drivers.

Next there is a word that contains flag bits indicating the type of driver.
Even though we are doing things related to disks which are block devices, we are
not actually a block device driver.  In fact, we are not any kind of device
driver.  We simply chose this mechanism to get our parameter table loaded very
early in the system initialization process.  So we will tell DOS that we are a
character device driver for the NUL device.  This is a trick specifically
included in DOS to handle not-a-real-device drivers.  DOS will never try to call
our driver except to call with the initialization function when we are loaded.

The next two entries are word offsets that point to the strategy and interrupt
routines for our device driver.  The strategy routine is called first with each
device request with all of the request parameters and is just supposed to save
them.  DOS then immediately calls the interrupt routine with no parameters
expecting it to process the request just given to the strategy routine.

(DOS obviously does not make any use of the existence of the two entry points.
Equally obviously, DOS was designed with the intent of someday becoming a true
multi-tasking operating system with asynchronous I/O.  Then the strategy routine
would set up queues of operations to be performed and actually initiate them
immediately or when appropriate hardware interrupts occurred.  DOS would call
the "interrupt" routine when it needed to get the completion status of the
requested operation.)

The last entry in the header for a character device is an 8-byte ASCII name of
the device, in our case 'NUL     '.

Our strategy routine is only supposed to be called once at initialization.  It
saves the pointers to the request parameters and returns.

The interrupt routine is also only supposed to be called once at initialization.
Carefully following the rules that it must save all of the registers that it
uses and that the stack provided by DOS is only big enough to hold the regis-
ters, it saves the registers and then switches to its own stack.

Next the interrupt routine modifies the header and code so that we will truly
act like a NUL device driver in case we ever get called again.  We set both the
interrupt routine pointer in the header to point to the same location as the
strategy routine and modify that code to simply return a normal completion
status on any call.

The next part of our code looks very much like DSKSET except that we must abide
by the device driver rules that we can only use DOS functions 01H-0CH and 30H.
We print the sign-on line, parse the parameters on the statement, and set the
interrupt vector pointer.  We get the location of the DEVICE=DSKDRV.BIN parame-
ters from the packet passed to us by DOS.  We have to change the interrupt
vector by hand since we are not supposed to use the DOS function that does that.
(It is easy to see why we cannot use the DOS file and directory functions while
we are still loading device drivers.  I suspect that some of the other functions
like set interrupt vector would actually work just fine, but we will play
strictly by the rules for safety's sake.)

We then tell the disk controller to use the new parameter table in exactly the
same way as we did in DSKSET.  Since this is the BIOS we are talking to rather
than DOS, we can use all of the disk functions.

Then we set the ending address of the driver to the last location that we need
to keep, print the completion message, and return to DOS.

DSKPARM is a common subroutine used by both DSKSET and DSKDRV that parses the
input parameters and builds the table.  DSKPARM consists of a main loop that
scans the input parameters until 16 bytes are found or the end of the list is
reached.  It calls the procedure GET_NUM to obtain each input value.

GET_NUM converts the next number from the input parameters.  It first skips any
leading blanks and then processes all characters until a comma or blank is
encountered.

GET_NUM uses an internal open procedure CNV_NUM to actually convert the charac-
ters to a number.  CNV_NUM is called once to do the conversion and then fallen
into to redo the conversion and exit.  This approach simplifies handling of hex
numbers.  The first time we assume that we will be converting a decimal number.
If any hex digits, X, or H are encountered, the base is changed so that the
second pass converts the numbers appropriately.

An error is detected if any characters other than 0-9, A-F, H, X, W, space, or
comma are encountered or if the value is greater than 65535.

PC/XT AND COMPATIBLES

CREATING YOUR OWN TABLE

DXTSET.COM and DXTDRV.BIN are the PC/XT analogues to DSKSET.COM and DSKDRV.BIN
respectively.  The PC/XT handles the tables so differently that it makes sense
to have separate programs for the PC/XT.     The usage is very similar to the
PC/AT versions except that the drive number is replaced by a type number.

DXTSET t p1,p2,p3,...
DEVICE=DXTDRV.BIN t p1,p2,p3,...

t is the number of the disk type being modified.  t will be a value in the range
0 to 15.  The PC/XT uses the same parameter table for both disk drives, so you
change the entry associated with the type you have set in the jumpers on the
controller.

All other parameters are the same as for the PC/AT version.  You may run DXTSET
or DXTDRV multiple times to change as many type entries as you wish.

HOW IT ALL WORKS

DXTSET and DXTDRV are very similar to their PC/AT counterparts and share the
common subroutine DSKPARM with them.

The PC/XT controller uses a single parameter table pointer stored at interrupt
location 41H for both disk drives.  This pointer gives the location of the base
(type 0) entry of the table and the controller indexes into the table using the
disk type that it reads from its jumpers.  A maximum of 16 entries may appear in
the table.

Since we have to have a table of 16 16-byte entries (256 bytes), we do not want
to make extra copies unnecessarily.  We find the current pointer to the table
using interrupt location 41H.  If it points to a location in the BIOS (segment
of 0C000H or greater), we copy the entire table to our memory area.  Otherwise,
we will modify the table in place.  This ensures that running DXTSET and DXTDRV
multiple times does not require any additional memory.

DSKPARM is called to convert the parameters.  The first field is treated as a
type number rather than a drive number, but everything else is the same.  The
table entry associated with the returned type number is changed.

If we had to create a copy of the table, we reserve the proper amount of memory.
Otherwise we simply exit to DOS.

SUMMARY

DSKSET and DSKDRV can save you $100 or more for the cost of a new disk con-
troller.  Any electrically compatible disk drive can be used with your con-
troller as long as your controller has a definition with the same number of
heads and sectors as your new disk.

                     THE FORMAT OF THE DISK PARAMETER TABLE

There are two disk parameter table formats, one for the PC/XT and one for the
PC/AT.  Both require essentially the same information.  In order to construct
your own parameter table you must have access to the technical specifications
about your disk drive.  Most dealers supply this with the drive.  You should be
sure that your dealer supplies it.  If you don't get it from your dealer, the
disk manufacturer can supply it to you.


PC/AT

The PC/AT disk controller BIOS and parameter tables are located in the system
BIOS.  The format of the PC/AT parameter table is:

BYTE         SIZE   DESCRIPTION
 0           Word   Total number of cylinders
 2           Byte   Number of read/write heads(surfaces)
 3           Word   Unused
 5           Word   Starting write precompensation cylinder
 7           Byte   Unused
 8           Byte   Control byte
                    Bit 7     No retry on disk errors
                    Bit 6     No retry on ECC errors
                    Bit 3     More than 8 heads
 9           Byte   Not used
10           Byte   Not used
11           Byte   Not used
12           Word   Landing zone cylinder
14           Byte   Sectors/track
15           Byte   Reserved

Offset 0(word) - Contains the total number of cylinders.  The drive specifica-
tions will supply this number.  This number is 2 larger than the number that
will be returned to you when you make a request to retrieve drive parameters.
The innermost cylinder is reserved as a test and landing zone cylinder and the
returned drive parameters give you the largest cylinder number (starting at 0)
rather than the number of cylinders.

Offset 2(byte) - Contains the total number of read/write heads.  This is also
the number of read/write surfaces.  Read the specifications carefully.  Some
disks have a clocking head/surface that is not used for data.  Be sure not to
include the clocking head in this count.  The number in this field is 1 greater
than the number returned by a request to retrieve drive parameters.  Again, the
returned drive parameters give the highest head number (starting at 0) rather
than the number of heads.

Offset 3(word) - Unused on a PC/AT.  Set to 0.

Offset 5(word) - Your drive specifications should identify the starting write
precompensation cylinder.  They may say that write precompensation is used for
the entire disk.  In that case put a 0 in this field.  They may say that write
precompensation is not used in which case you should put 0xFFFF in this field.

Offset 7(byte) - Unused on a PC/AT.  Set to 0.

Offset 8(byte) - Control byte.  Set bit 3 to a 1 if your disk has more than 8
read/write heads.  Bits 6 or 7 may be set if you do not want the controller to
do retries.  These bits are invariably 0.

Offset 9(byte) - Unused on a PC/AT.  Set to 0.

Offset 10(byte) - Unused on a PC/AT.  Set to 0.

Offset 11(byte) - Unused on a PC/AT.  Set to 0.

Offset 12(word) - Landing zone.  Value to be used by park programs to move heads
to.  Often equal to the total number of cylinders value at offset 0, but your
drive specifications may define a special value to be placed here.

Offset 14(byte) - Sectors per track.  Usually 17.  If your drive specifications
do not indicate what value to use, try 17.  Otherwise you may compute it from
other information given in the drive specifications.  Drive specifications
usually give the total number of bits per track, the size of the sector(record)
headers, and the size of any required gaps.  Sometimes gaps are specified in
minimum and maximum time intervals and you will have to convert that to bits
using the rotational rate (often 3600 RPM) and the total number of bits per
track.  Sector sizes are always 512 bytes unless you have a specially modified
version of DOS.

Offset 15(byte) - Reserved.  Set to 0.


PC/XT

The PC/XT parameter table is located on the BIOS chip on the disk controller
card.  This allowed the addition of optional controllers to a PC that was not
originally designed to accommodate them.  Several of the fields are the same as
in the PC/AT parameter table.  Those fields will be identified but not explained
again.

BYTE         SIZE   DESCRIPTION
 0           Word   Total number of cylinders
 2           Byte   Number of read/write heads(surfaces)
 3           Word   Reduced write current cylinder
 5           Word   Starting write precompensation cylinder
 7           Byte   Maximum ECC data burst length
 8           Byte   Control byte
                    Bit 7     No retry on disk errors
                    Bit 6     No retry on ECC errors
                    Bit 3     More than 8 heads
                    Bits 0-2     Step rate
 9           Byte   Timeout value for normal read/write operations
10           Byte   Timeout value for format operations
11           Byte   Timeout value for disk check operations
12           Word   Unused
14           Byte   Unused
15           Byte   Reserved

Offset 3(word) - Reduced write current cylinder.  Your drive specifications
should give this value.  It is often equal to the starting write precompensation
cylinder.  In fact, the PC/AT controller assumes they are equivalent and only
uses a single value.

Offset 7(byte) - Maximum ECC data burst length.  The maximum number of bits that
the ECC can correct.  The first and last bits in error in any sector must be
within this length (inclusive) of each other or the ECC cannot correct the
error.  Some controllers do not use this value.  If all the values in your
controller's table are 0 or the same, just use that value.

Offset 8(byte) - Control byte.  Bits 0-2 specify the head stepping rate on
cylinder-to-cylinder motion.

Offsets 9-11(byte) - Timeout values.  These values are used by the BIOS software
to timeout disk operations.  Normally all entries in the BIOS table contain the
same values and you should just use those.  However, if your disk is very slow
in transfer rate or access time, you may need to use increased values.

Offset 12(word)   - Unused on a PC/XT.  This is the landing zone field and you
may want to put your drive's landing zone in it.  The BIOS does not use it, but
some PARK programs do.

Offset 14(byte)   - Unused on a PC/XT.  This is the sectors per track field on a
PC/AT and should be 0 or 17.